Skip to main content

Phase 2 — Configure Data & Metrics Accuracy

In this phase, you will configure the settings that determine how LinearB interprets your engineering data. These choices directly affect metric accuracy across Dashboards, DORA, Goals, and reports.…

Steven Silverstone
Updated by Steven Silverstone

In this phase, you will configure the settings that determine how LinearB interprets your engineering data. These choices directly affect metric accuracy across Dashboards, DORA, Goals, and reports.

Goal of this phase: Ensure delivery metrics reflect real production work (not noise).

Estimated time: 15–30 minutes

Before You Begin

  • Complete Phase 1 and confirm Git syncing is active.
  • Make sure you know (or can confirm) how your organization defines a production release.
  • If multiple teams release differently, decide whether you want one org-wide approach or per-repo overrides.
Enterprise best practice
Start with an org-wide baseline configuration, then override per repository only when needed. This keeps reporting consistent and reduces long-term maintenance.

Step 1 — Configure Release Detection

Release detection is required for accurate deployment-related metrics such as: Deployment Frequency, Lead Time, and Deploy Time. It also determines when work is considered “released to production.”

Supported Release Detection Methods

Method A — Release by Tag

  • Use this if you tag releases.
  • Triggered when a Git push occurs to a tagged commit.
  • You can filter release tags using a regex pattern (prefix/suffix).

Method B — Release by PR Merge to a Dedicated Branch

  • Use this if merging PRs into a release branch (for example, main) indicates deployment.
  • Set which branches LinearB should treat as “release branches” using regex.
  • Note: This method may cause Deploy Time to register as 0 in some workflows (because merge is treated as deploy).

Method C — Release by Direct Merge to a Branch

  • Use this if your teams deploy via direct merges without PRs.
  • LinearB detects the merged commit and marks included work as deployed.
  • Set which branches LinearB listens to using regex.

Method D — Release by Deployment API

Use the Deployment API when your source of truth for release detection is your CI/CD platform or deployment system. In this method, LinearB detects releases based on reported deployment events.

  • Use this if your source of truth is CI/CD or a deployment system.
  • Best for high accuracy and multi-stage delivery workflows.
  • Deployments are matched to merged branches using Git ancestry.
  • Use this method when you want release detection to be driven by actual deployment activity rather than merge behavior alone.
Note: Although this method is used for release detection in LinearB, the underlying API is named the Deployment API because it reports deployment events from your delivery system.
Deployment API reference
See: Deployment API

Where to Configure Release Detection

Set the organization-wide release detection method
  1. Go to Company Settings → Advanced.
  2. Find the Release Detection section.
  3. Select the method your organization uses.
  4. Click Save.
Override release detection per repository (when needed)

Use per-repo overrides only when specific repositories have a different deployment process than the organization default.

  1. Go to Company Settings → Git.
  2. Click the gear icon next to the repository.
  3. In Release Detection, select the repo-specific method.
  4. Click Save.

Step 2 — Configure Branch Exclusions

Branch exclusions remove non-production branches from key calculations. This prevents work on long-lived non-release branches (or test branches) from distorting metrics.

Where to Configure

Set organization-wide branch exclusions
  1. Go to Company Settings → Advanced.
  2. Find Exclude Branches.
  3. Add one regular expression per line.
  4. Click Save.
Override branch exclusions per repository
  1. Go to Company Settings → Git.
  2. Click the gear icon next to the repository.
  3. Update Exclude Branches for that repo.
  4. Click Save.
Tip
Exclude branches that represent environments or staging lanes that should not count as production delivery (e.g., staging, integration, develop).

Step 3 — Configure File Exclusions

File exclusions prevent non-code changes from inflating metrics such as PR Size and New Code. This is especially important for compiled assets, lock files, generated bundles, and documentation-only updates.

Where to Configure

Set organization-wide file exclusions
  1. Go to Company Settings → Advanced.
  2. Find Exclude File Extensions.
  3. Add one regular expression per line.
  4. Click Save.
Override file exclusions per repository
  1. Go to Company Settings → Git.
  2. Click the gear icon next to the repository.
  3. Update Exclude File Extensions for that repo.
  4. Click Save.

Step 4 — Configure Draft Pull Request Handling

Draft pull requests represent early or incomplete work and can distort: Cycle Time, Pickup Time, and Review Time.

LinearB can treat a PR as draft based on:

  • Configured labels (recommended)
  • A configured title regex pattern (optional safety net)

Where to Configure

Set organization-wide draft PR settings
  1. Go to Company Settings → Advanced.
  2. Find Draft Pull Requests.
  3. Configure labels and (optional) title regex.
  4. Click Save.
Override draft PR settings per repository
  1. Go to Company Settings → Git.
  2. Click the gear icon next to the repository.
  3. Update Draft Pull Requests settings for that repo.
  4. Click Save.
Recommendation
Standardize on 1–2 labels (for example wip and do_not_merge) across all teams.

Step 5 — Exclude Bot Accounts

Bot commits and automated PR activity can inflate metrics and create noise. Exclude bots to keep dashboards representative of real developer work.

  • Send bot email addresses to LinearB Support for exclusion.
  • Bot exclusion will be configurable in-product in a future release.

Need help? Contact Support

Step 6 — Configure Metric Calculation Method

This setting determines how LinearB aggregates time-based metrics across multiple pull requests, such as Cycle Time, Pickup Time, Review Time, and Deploy Time.

Supported aggregation methods

  • Average (Mean) — sensitive to outliers
  • Median — stable “typical” value
  • 75th Percentile — captures the typical upper range (commonly used)
  • 90th Percentile — highlights tail behavior (slowest cases)

How to choose

  • Median: best if you want a stable measure and your org has occasional very large PRs.
  • 75th percentile: best for a realistic enterprise view that reflects friction without being dominated by extremes.
  • 90th percentile: best if you want high sensitivity to delays.
  • Average: best when workflows are consistent and outliers are rare.

Where to configure

  1. Go to Company Settings → General.
  2. Find Metrics Calculation.
  3. Select the aggregation method.
  4. Click Save.

Verify Phase 2 — Confirm Accuracy Settings Are Applied

Before moving to Phase 3, confirm the settings are configured correctly.

Release Detection

  • You can clearly state which method your organization uses.
  • The selected method matches how production releases actually occur.

Exclusions

  • Branch exclusions remove non-production branches.
  • File exclusions remove generated or non-code files.
  • Draft PR handling matches your organization’s draft conventions.

Metrics aggregation

  • The selected calculation method matches how leadership expects to measure performance.
If metrics look wrong later:
  • Re-check release detection (most common root cause).
  • Confirm exclusions match real branch and file patterns.
  • Validate that bot accounts are excluded.

Next Step

Once accuracy settings are configured, define teams, users, and ownership mappings.

Continue to Phase 3 — Organize Teams & Ownership →

How did we do?

Phase 1 - Connect Your Systems

Phase 3 — Organize Teams & Ownership

Contact